Skip to content

Throttle playback progress publishers to reduce UI lag#1510

Open
matalvernaz wants to merge 3 commits into
TortugaPower:developfrom
matalvernaz:fix/playback-ui-throttle
Open

Throttle playback progress publishers to reduce UI lag#1510
matalvernaz wants to merge 3 commits into
TortugaPower:developfrom
matalvernaz:fix/playback-ui-throttle

Conversation

@matalvernaz

Copy link
Copy Markdown
Contributor

Summary

Fixes #1509

  • Adds 500ms throttle to .bookPlaying and .listeningProgressChanged subscribers in PlayerViewModel (keeps slider updates smooth while halving redraws)
  • Adds 1s throttle to currentProgressPublisher and immediateProgressUpdatePublisher in ItemProgressView (matches the existing folderProgressUpdated throttle)

Context

The AVPlayer periodic time observer fires every 1 second. Without throttling, each tick triggers recalculateProgress() (updating ~6 @Published properties) and redraws every visible library row's progress ring. On lower-powered devices like the iPhone SE 2, this causes noticeable lag during playback.

Test plan

  • Play an audiobook and verify the player slider/time labels still update smoothly
  • Verify library list progress rings still update during playback
  • Verify no visual stutter when scrolling the library during playback
  • Test on a lower-powered device (iPhone SE 2 / similar) if available

🤖 Generated with Claude Code

Matthew Alvernaz and others added 2 commits May 5, 2026 03:29
The .bookPlaying and .listeningProgressChanged notifications fire every
second from the AVPlayer periodic time observer, causing recalculateProgress()
to update multiple @published properties on every tick. Similarly,
currentProgressPublisher and immediateProgressUpdatePublisher in
ItemProgressView trigger per-second redraws for every visible library row.

On lower-powered devices (e.g. iPhone SE 2), this causes noticeable UI lag
during playback. This adds 500ms throttling on the player progress publishers
(keeping slider updates smooth) and 1s throttling on the library progress
views (matching the existing folderProgressUpdated throttle).

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
PlayerViewModel and ItemProgressView were both using literal throttle windows
(500ms / 1s) in multiple subscriber pipelines. Promoted each to a documented
private static constant on the owning type so the cadence is discoverable and
the rationale (audio-tick suppression vs SwiftUI redraw cost) lives next to
the value.
@matalvernaz

Copy link
Copy Markdown
Contributor Author

Caught up to current develop. Folded in a follow-up commit that pulls the throttle windows out into named constants with short docstrings explaining why each duration was chosen — the same literal 500 ms / 1 s shows up in a few publisher pipelines, better to have one place to tune them.

@matalvernaz matalvernaz force-pushed the fix/playback-ui-throttle branch from bd6faac to 24a926a Compare May 5, 2026 10:30
@GianniCarlo

Copy link
Copy Markdown
Collaborator

I have to double check this, I have an iPhone SE 2 lent to someone, I just have to track it down, I'll put this on hold in the meantime

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

UI lag during playback on lower-powered devices (iPhone SE 2)

2 participants